ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94a.txt/000206_icon-group-sender _Mon Aug 15 15:55:47 1994.msg

Internet Message Format | 1994-08-19 | 6KB

Received: by cheltenham.cs.arizona.edu; Mon, 15 Aug 1994 14:01:26 MST
To: [e-mail]
Date: 15 Aug 1994 15:55:47 GMT
From: [e-mail] (Marc Espie)
Message-Id: <32o363$[e-mail]>
Organization: Ecole Normale Superieure, PARIS, France
Sender: [e-mail]
References: <[e-mail]>, <[e-mail]>
Subject: Re: Generators
Status: R
Errors-To: [e-mail]

In article <[e-mail]>,
Larry Wall <[e-mail]> wrote:
>In article <[e-mail]> [e-mail] (Micha Berger) writes:
>: Icon has a concept of generator. It's been a while since I last used Icon,
>: but here's the basic concept in an ad-hoc Perl-like syntax.
>:
>: Generators are functions/operators that return a sequence of values. For
>: example, index(/re/, $string) could return the first location of /re/ in
>: $string, followed by the second, followed by the third...
>
>More specifically, generators can, on demand, return the next answer in a
>sequence of potential answers.
>
>: There are two ways this is used. The first is that if an expression "fails", it
>: can be reevaluated using the next value: e.g.
>:     $loc = index(/re/, $string) > 32;
>: will set $loc to a location greater than 32, or, undef.
>
>Just out of curiosity, what prevents it from returning the *next*
>location greater than 32 the next time you evaluate it?  Is there an
>implicit cut operation?

Implicit ? no... explicit, yes, and it's not a dirty concept like in Prolog
for instance, but perfectly clean, based upon syntactic entities.

In that particular case, instantiation does cut the backtracking. In icon,
you write:
loc := 32 < find(s1, s2)
because:
- <, when it succeeds, returns the expression on the LEFT, not the right
(which is reasonable, since it allows for 0 < i < 10)
- := is the normal instantiation operator. There also exists a reversible
one (<-) which you use VERY rarely.
- the backtracking would be cut at the end of the expression anyway. EVERY
expression is closed for backtracking. And there are other control points where
backtracking can not occur.

>
>: The other is an "every" iterator:
>:     every(index(/re/, $string)) {
>:         ...
>:     }
>:
>: (One neat little feature, it meant that || could be read to mean "concatenate
>: two sequences" and still retain its current functionality.)
>
>Well, yes, depending on what's demanded by the context.  Perl has a
>simpler demand structure than Icon, and people still complain about it.
>
>: I was wondering if there is some easy way to get similar functionality out of
>: Perl.
>
>Yes and no.  There are a few operators in Perl that behave like
>generators in scalar context, such as <> and m//g.  And it's easy
>enough to write functions that remember their state and return the
>"next" thing.  But the state is explicit, and doesn't differentiate who
>called the function (unless you're really sneaky).  And lists in Perl
>are always completely constructed before they are passed on to the next
>processing element.

In Icon, you differentiate the other way. The implicit state differentiates
where the function was called. If you want an expression that can be resumed
elsewhere, you encapsulate it into a coexpression. Here is the classic
`build identifiers on the fly' in Icon.
procedure newid
    i := 0
    repeat
        {
        i +:= 1
        suspend "a"||i
        }
end

called thus:
gen := create newid()
id:= @gen
each time you wish for a new id.


and that way, you can avoid constructing some lists on the fly, which is
*sometimes* a win.

>
>I basically don't like languages that try to help you by keeping track
>of a lot of implicit state.  I don't think most ordinary folks like
>them either.  Regular expressions are already dangerously close to the
>limits of mortal endurance, which is why the use of them in Perl is
>rigidly circumscribed.  I'm somewhat allergic to the rampant uncertainty
>engendered by pervasive implicit backtracking.  (I have similar feelings
>about the way shells do pervasive string interpolation.)  Perl is very
>much a what-you-see-is-what-it-does language.  When you're fighting with
>one of the good ol' boys, just stand up straight and start boxing...

There is no pervasive implicit backtracking in Icon, it's very well-bounded
and works just like an ordinary sequential language, except where you NEED
backtracking.

I'd contend Icon is almost in the same league as Perl. After all, you don't
see behind the scene garbage-collecting in Perl either.

>
>Like all forms of abstraction, generators are a mixed blessing.
>Icon's popularity stems directly from its abstraction facilities.
>Unfortunately, so does its *lack* of popularity.

I don't know, it seems to me that nobody is particularly pushing Icon these
days... and it tends to be a lot bigger than perl, and a trifle slower and
not to be aimed at the same goals... not the same concision as far as work
on regular expressions go, but much more powerful for many other problems
dealing with string analysis (Icon doesn't have regular expressions...)
>
>That's just my $.02 worth (multiplied, of course, by however many more
>subsribers there are to comp.lang.perl than to comp.lang.icon).
>
>Larry

I've taken upon myself to crosspost this to comp.lang.icon where lots of nice
guys will be able to give a better analysis of all this than me.

Oh, and by the way, I use regularly Icon AND Perl, not for quite the same
problems, obviously.


--
[nosave]<http://acacia.ens.fr:8080/home/espie/index.html>
`Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai)
`$@0>@n(J $@$N$3$H!<9%$-$@$h!#(J' ($@$"$NF|$K5"$j$?$$(J)(B
    Marc Espie ([e-mail])